Proteins, pools, and slawx in processing environments

ABSTRACT

Embodiments described herein include mechanisms for encapsulating data that needs to be shared between or across processes. These mechanisms include slawx (plural of “slaw”), proteins, and pools. Generally, slawx provide the lowest-level of data definition for inter-process exchange, proteins provide mid-level structure and hooks for querying and filtering, and pools provide for high-level organization and access semantics. Slawx includes a mechanism for efficient, platform-independent data representation and access. Proteins provide a data encapsulation and transport scheme using slawx as the payload. Pools provide structured and flexible aggregation, ordering, filtering, and distribution of proteins within a process, among local processes, across a network between remote or distributed processes, and via longer term (e.g. on-disk, etc.) storage.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/705,077, filed 14 Sep. 2017, which is a continuation of U.S. patentapplication Ser. No. 13/850,837, filed 26 Mar. 2013, which is acontinuation of U.S. patent application Ser. No. 12/109,263, filed 24Apr. 2008, now issued as U.S. Pat. No. 8,407,725, which claims thebenefit of U.S. Provisional Patent Application Ser. No. 60/926,116,filed 24 Apr. 2007, which are each incorporated herein in their entiretyby this reference.

The present application is related to U.S. patent application Ser. No.11/350,697, filed 8 Feb. 2006, which claims the benefit of U.S.Provisional Patent Application 60/651,290, filed 8 Feb. 2005, which areeach incorporated herein in their entirety by this reference.

TECHNICAL FIELD

Embodiments are described relating to the representation, manipulation,and exchange of data within and between computing processes.

BACKGROUND

Conventional programming environments do not fully supportmulti-computer processing unit (CPU) and cross-network execution, orflexible sharing of data between large numbers of computing processes.

For example, conventional user-facing computing platforms (e.g., OS X,Microsoft Windows, X Windows atop UNIX) provide facilities fortransmitting event data between processes. But these existing mechanismsall suffer from shortcomings that make it difficult to buildmulti-process and multi-machine applications, and that force usersworking in more than one programming language to jump throughfrustrating hoops. For example, conventional event frameworks arestrongly typed, which makes them inflexible, privileges the assumptionsof the systems vendor over the application programmer, and forms amismatch with the facilities of increasingly popular dynamic languages(e.g., Ruby, Python and Perl). The conventional frameworks are alsoconfigured only to support point-to-point data transfers, which makescoordinating the activity of more than a few distinct processesdifficult or impossible. The conventional frameworks are also stronglydependent on particular local, in-memory data structures, which rendersthem unsuited for on-disk storage or transmission across a network.

INCORPORATION BY REFERENCE

Each patent, patent application, and/or publication mentioned in thisspecification is herein incorporated by reference in its entirety to thesame extent as if each individual patent, patent application, and/orpublication was specifically and individually indicated to beincorporated by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a processing environment including datarepresentations using slawx, proteins, and pools, under an embodiment.

FIG. 2 is a block diagram of a protein, under an embodiment.

FIG. 3 is a block diagram of a descrip, under an embodiment.

FIG. 4 is a block diagram of an ingest, under an embodiment.

FIG. 5 is a block diagram of a slaw, under an embodiment.

FIG. 6A is a block diagram of a protein in a pool, under an embodiment.

FIGS. 6B1 and 6B2 show a slaw header format, under an embodiment.

FIG. 6C is a flow diagram for using proteins, under an embodiment.

FIG. 6D is a flow diagram for constructing or generating proteins, underan embodiment.

FIG. 7 is a block diagram of a processing environment including dataexchange using slawx, proteins, and pools, under an embodiment.

FIG. 8 is a block diagram of a processing environment including multipledevices and numerous programs running on one or more of the devices inwhich the Plasma constructs (e.g., pools, proteins, and slaw) are usedto allow the numerous running programs to share and collectively respondto the events generated by the devices, under an embodiment.

FIG. 9 is a block diagram of a processing environment including multipledevices and numerous programs running on one or more of the devices inwhich the Plasma constructs (e.g., pools, proteins, and slaw) are usedto allow the numerous running programs to share and collectively respondto the events generated by the devices, under an alternative embodiment.

FIG. 10 is a block diagram of a processing environment includingmultiple input devices coupled among numerous programs running on one ormore of the devices in which the Plasma constructs (e.g., pools,proteins, and slaw) are used to allow the numerous running programs toshare and collectively respond to the events generated by the inputdevices, under another alternative embodiment.

FIG. 11 is a block diagram of a processing environment includingmultiple devices coupled among numerous programs running on one or moreof the devices in which the Plasma constructs (e.g., pools, proteins,and slaw) are used to allow the numerous running programs to share andcollectively respond to the graphics events generated by the devices,under yet another alternative embodiment.

FIG. 12 is a block diagram of a processing environment includingmultiple devices coupled among numerous programs running on one or moreof the devices in which the Plasma constructs (e.g., pools, proteins,and slaw) are used to allow stateful inspection, visualization, anddebugging of the running programs, under still another alternativeembodiment.

FIG. 13 is a block diagram of a processing environment includingmultiple devices coupled among numerous programs running on one or moreof the devices in which the Plasma constructs (e.g., pools, proteins,and slaw) are used to allow influence or control the characteristics ofstate information produced and placed in that process pool, under anadditional alternative embodiment.

DETAILED DESCRIPTION

Embodiments are taught herein that include a novel programming orprocessing environment that enables and encourages large scalemulti-process interoperation. The embodiments provided herein overcomeissues in conventional programming environments which do not fullysupport multi computer processing unit (CPU) and cross-networkexecution, or flexible sharing of data between large numbers ofcomputing processes.

Methods and systems are described herein for encapsulating data that isto be shared between or across processes. These mechanisms include slawx(plural of “slaw”), proteins, and pools. Generally, slawx provide thelowest-level of data definition for inter-process exchange, proteinsprovide mid-level structure and hooks for querying and filtering, andpools provide for high-level organization and access semantics. Slawxinclude a mechanism for efficient, platform-independent datarepresentation and access. Proteins provide a data encapsulation andtransport scheme using slawx as the payload. Pools provide structuredand flexible aggregation, ordering, filtering, and distribution ofproteins within a process, among local processes, across a networkbetween remote or distributed processes, and via longer term (e.g.on-disk, etc.) storage.

The configuration and implementation of the embodiments described hereininclude several constructs that together enable numerous capabilities.For example, the embodiments described herein provide efficient exchangeof data between large numbers of processes. The embodiments describedherein also provide flexible data “typing” and structure, so that widelyvarying kinds and uses of data are supported. Furthermore, embodimentsdescribed herein include flexible mechanisms for data exchange (e.g.,local memory, disk, network, etc.), all driven by substantially similarapplication programming interfaces (APIs). Moreover, embodimentsdescribed enable data exchange between processes written in differentprogramming languages. Additionally, embodiments described herein enableautomatic maintenance of data caching and aggregate state.

In the following description, numerous specific details are introducedto provide a thorough understanding of, and enabling description for,embodiments described herein. One skilled in the relevant art, however,will recognize that these embodiments can be practiced without one ormore of the specific details, or with other components, systems, etc. Inother instances, well-known structures or operations are not shown, orare not described in detail, to avoid obscuring aspects of the disclosedembodiments.

The following terms are intended to have the following general meaningas they are used herein. The term “process” as used herein means acomputer program executing for a period of time. This execution may beinterrupted by pauses or transfers between processors or machines, sothat a process is possibly suspended indefinitely and “serialized” or“marshaled” to disk, across a memory bus, or over a network. Thepreceding meaning can include other meanings as understood by oneskilled in the art.

The term “device” as used herein means any processor-based devicerunning one or more programs or algorithms, any processor-based devicerunning under one or more programs or algorithms and/or any devicecoupled or connected to a processor-based device running one or moreprograms or algorithms and/or running under one or more programs oralgorithms. The term “event” as used herein means any event associatedwith a running or executing program or algorithm, a processor-baseddevice and/or a device coupled or connected to a processor-based device(e.g., an event can include, but is not limited to, an input, an output,a control, a state, a state change, an action, data (regardless offormat of the data or stage in the processing from with which the datais associated), etc.).

FIG. 1 is a block diagram of a processing environment including datarepresentations using slawx, proteins, and pools, under an embodiment.The principal constructs of the embodiments presented herein includeslawx (plural of “slaw”), proteins, and pools. Slawx as described hereinincludes a mechanism for efficient, platform-independent datarepresentation and access. Proteins, as described in detail herein,provide a data encapsulation and transport scheme, and the payload of aprotein of an embodiment includes slawx. Pools, as described herein,provide structured yet flexible aggregation, ordering, filtering, anddistribution of proteins. The pools provide access to data, by virtue ofproteins, within a process, among local processes, across a networkbetween remote or distributed processes, and via ‘longer term’ (e.g.on-disk) storage.

FIG. 2 is a block diagram of a protein, under an embodiment. The proteinincludes a length header, a descrip, and an ingest. Each of the descripand ingest includes slaw or slawx, as described in detail below.

FIG. 3 is a block diagram of a descrip, under an embodiment. The descripincludes an offset, a length, and slawx, as described in detail below.

FIG. 4 is a block diagram of an ingest, under an embodiment. The ingestincludes an offset, a length, and slawx, as described in detail below.

FIG. 5 is a block diagram of a slaw, under an embodiment. The slawincludes a type header and type-specific data, as described in detailbelow.

FIG. 6A is a block diagram of a protein in a pool, under an embodiment.The protein includes a length header (“protein length”), a descripsoffset, an ingests offset, a descrip, and an ingest. The descripsincludes an offset, a length, and a slaw. The ingest includes an offset,a length, and a slaw.

The protein as described herein is a mechanism for encapsulating datathat needs to be shared between processes, or moved across a bus ornetwork or other processing structure. As an example, proteins providean improved mechanism for transport and manipulation of data includingdata corresponding to or associated with user interface events; inparticular, the user interface events of an embodiment include those ofthe gestural interface described in U.S. patent application Ser. No.11/350,697, filed Feb. 8, 2006, and herein incorporated by reference inits entirety. As a further example, proteins provide an improvedmechanism for transport and manipulation of data including, but notlimited to, graphics data or events, and state information, to name afew. A protein is a structured record format and an associated set ofmethods for manipulating records. Manipulation of records as used hereinincludes putting data into a structure, taking data out of a structure,and querying the format and existence of data. Proteins are configuredto be used via code written in a variety of computer languages. Proteinsare also configured to be the basic building block for pools, asdescribed herein. Furthermore, proteins are configured to be nativelyable to move between processors and across networks while maintainingintact the data they include.

In contrast to conventional data transport mechanisms, proteins areuntyped. While being untyped, the proteins provide a powerful andflexible pattern-matching facility, on top of which “type-like”functionality is implemented. Proteins configured as described hereinare also inherently multi-point (although point-to-point forms areeasily implemented as a subset of multi-point transmission).Additionally, proteins define a “universal” record format that does notdiffer (or differs only in the types of optional optimizations that areperformed) between in-memory, on-disk, and on-the-wire (network)formats, for example.

Referring to FIGS. 2 and 6, a protein of an embodiment is a linearsequence of bytes. Within these bytes are encapsulated a descrips listand a set of key-value pairs called ingests. The descrips list includesan arbitrarily elaborate but efficiently filterable per-protein eventdescription. The ingests include a set of key-value pairs that comprisethe actual contents of the protein.

Proteins' concern with key-value pairs, as well as some core ideas aboutnetwork-friendly and multi-point data interchange, is shared withearlier systems that privilege the concept of “tuples” (e.g., Linda,Jini). Proteins differ from tuple-oriented systems in several majorways, including the use of the descrips list to provide a standard,optimizable pattern matching substrate. Proteins also differ fromtuple-oriented systems in the rigorous specification of a record formatappropriate for a variety of storage and language constructs, along withseveral particular implementations of “interfaces” to that recordformat.

Turning to a description of proteins, the first four or eight bytes of aprotein specify the protein's length, which must be a multiple of 16bytes in an embodiment. This 16-byte granularity ensures thatbyte-alignment and bus-alignment efficiencies are achievable oncontemporary hardware. A protein that is not naturally “quad-wordaligned” is padded with arbitrary bytes so that its length is a multipleof 16 bytes.

The length portion of a protein has the following format: 32 bitsspecifying length, in big-endian format, with the four lowest-order bitsserving as flags to indicate macro-level protein structurecharacteristics; followed by 32 further bits if the protein's length isgreater than 2{circumflex over ( )}32 bytes.

The 16-byte-alignment proviso of an embodiment means that the lowestorder bits of the first four bytes are available as flags. And so thefirst three low-order bit flags indicate whether the protein's lengthcan be expressed in the first four bytes or requires eight, whether theprotein uses big-endian or little-endian byte ordering, and whether theprotein employs standard or non-standard structure, respectively, butthe protein is not so limited. The fourth flag bit is reserved forfuture use.

If the eight-byte length flag bit is set, the length of the protein iscalculated by reading the next four bytes and using them as thehigh-order bytes of a big-endian, eight-byte integer (with the fourbytes already read supplying the low-order portion). If thelittle-endian flag is set, all binary numerical data in the protein isto be interpreted as little-endian (otherwise, big-endian). If thenon-standard flag bit is set, the remainder of the protein does notconform to the standard structure to be described below.

Non-standard protein structures will not be discussed further herein,except to say that there are various methods for describing andsynchronizing on non-standard protein formats available to a systemsprogrammer using proteins and pools, and that these methods can beuseful when space or compute cycles are constrained. For example, theshortest protein of an embodiment is sixteen bytes. A standard-formatprotein cannot fit any actual payload data into those sixteen bytes (thelion's share of which is already relegated to describing the location ofthe protein's component parts). But a non-standard format protein couldconceivably use 12 of its 16 bytes for data. Two applications exchangingproteins could mutually decide that any 16-byte-long proteins that theyemit always include 12 bytes representing, for example, 12 8-bit sensorvalues from a real-time analog-to-digital converter.

Immediately following the length header, in the standard structure of aprotein, two more variable-length integer numbers appear. These numbersspecify offsets to, respectively, the first element in the descrips listand the first key-value pair (ingest). These offsets are also referredto herein as the descrips offset and the ingests offset, respectively.The byte order of each quad of these numbers is specified by the proteinendianness flag bit. For each, the most significant bit of the firstfour bytes determines whether the number is four or eight bytes wide. Ifthe most significant bit (msb) is set, the first four bytes are the mostsignificant bytes of a double-word (eight byte) number. This is referredto herein as “offset form”. Use of separate offsets pointing to descripsand pairs allows descrips and pairs to be handled by different codepaths, making possible particular optimizations relating to, forexample, descrips pattern-matching and protein assembly. The presence ofthese two offsets at the beginning of a protein also allows for severaluseful optimizations.

Most proteins will not be so large as to require eight-byte lengths orpointers, so in general the length (with flags) and two offset numberswill occupy only the first three bytes of a protein. On many hardware orsystem architectures, a fetch or read of a certain number of bytesbeyond the first is “free” (e.g., 16 bytes take exactly the same numberof clock cycles to pull across the Cell processor's main bus as a singlebyte).

In many instances it is useful to allow implementation-specific orcontext-specific caching or metadata inside a protein. The use ofoffsets allows for a “hole” of arbitrary size to be created near thebeginning of the protein, into which such metadata may be slotted. Animplementation that can make use of eight bytes of metadata gets thosebytes for free on many system architectures with every fetch of thelength header for a protein.

The descrips offset specifies the number of bytes between the beginningof the protein and the first descrip entry. Each descrip entry comprisesan offset (in offset form, of course) to the next descrip entry,followed by a variable-width length field (again in offset format),followed by a slaw. If there are no further descrips, the offset is, byrule, four bytes of zeros. Otherwise, the offset specifies the number ofbytes between the beginning of this descrip entry and the next one. Thelength field specifies the length of the slaw, in bytes.

In most proteins, each descrip is a string, formatted in the slaw stringfashion: a four-byte length/type header with the most significant bitset and only the lower 30 bits used to specify length, followed by theheader's indicated number of data bytes. As usual, the length headertakes its endianness from the protein. Bytes are assumed to encode UTF-8characters (and thus—nota bene—the number of characters is notnecessarily the same as the number of bytes).

The ingests offset specifies the number of bytes between the beginningof the protein and the first ingest entry. Each ingest entry comprisesan offset (in offset form) to the next ingest entry, followed again by alength field and a slaw. The ingests offset is functionally identical tothe descrips offset, except that it points to the next ingest entryrather than to the next descrip entry.

In most proteins, every ingest is of the slaw cons type comprising atwo-value list, generally used as a key/value pair. The slaw cons recordcomprises a four-byte length/type header with the second mostsignificant bit set and only the lower 30 bits used to specify length; afour-byte offset to the start of the value (second) element; thefour-byte length of the key element; the slaw record for the keyelement; the four-byte length of the value element; and finally the slawrecord for the value element.

Generally, the cons key is a slaw string. The duplication of data acrossthe several protein and slaw cons length and offsets field provides yetmore opportunity for refinement and optimization.

The construct used under an embodiment to embed typed data insideproteins, as described above, is a tagged byte-sequence specificationand abstraction called a “slaw” (the plural is “slawx”). A slaw is alinear sequence of bytes representing a piece of (possibly aggregate)typed data, and is associated with programming-language-specific APIsthat allow slawx to be created, modified and moved around between memoryspaces, storage media, and machines. The slaw type scheme is intended tobe extensible and as lightweight as possible, and to be a commonsubstrate that can be used from any programming language.

The desire to build an efficient, large-scale inter-processcommunication mechanism is the driver of the slaw configuration.Conventional programming languages provide sophisticated data structuresand type facilities that work well in process-specific memory layouts,but these data representations invariably break down when data needs tobe moved between processes or stored on disk. The slaw architecture is,first, a substantially efficient, multi-platform friendly, low-leveldata model for inter-process communication.

But even more importantly, slawx are configured to influence, togetherwith proteins, and enable the development of future computing hardware(microprocessors, memory controllers, disk controllers). A few specificadditions to, say, the instruction sets of commonly availablemicroprocessors make it possible for slawx to become as efficient evenfor single-process, in-memory data layout as the schema used in mostprogramming languages.

Each slaw comprises a variable-length type header followed by atype-specific data layout. In an example embodiment, which supports fullslaw functionality in C, C++ and Ruby for example, types are indicatedby a universal integer defined in system header files accessible fromeach language. More sophisticated and flexible type resolutionfunctionality is also enabled: for example, indirect typing viauniversal object IDs and network lookup.

The slaw configuration of an embodiment allows slaw records to be usedas objects in language-friendly fashion from both Ruby and C++, forexample. A suite of utilities external to the C++ compiler sanity-checkslaw byte layout, create header files and macros specific to individualslaw types, and auto-generate bindings for Ruby. As a result,well-configured slaw types are quite efficient even when used fromwithin a single process. Any slaw anywhere in a process's accessiblememory can be addressed without a copy or “deserialization” step.

Slaw functionality of an embodiment includes API facilities to performone or more of the following: create a new slaw of a specific type;create or build a language-specific reference to a slaw from bytes ondisk or in memory; embed data within a slaw in type-specific fashion;query the size of a slaw; retrieve data from within a slaw; clone aslaw; and translate the endianness and other format attributes of alldata within a slaw. Every species of slaw implements the abovebehaviors.

FIG. 6B shows a slaw header format, under an embodiment. A detaileddescription of the slaw follows.

The internal structure of each slaw optimizes each of type resolution,access to encapsulated data, and size information for that slawinstance. In an embodiment, the full set of slaw types is by designminimally complete, and includes: the slaw string; the slaw cons (i.e.dyad); the slaw list; and the slaw numerical object, which itselfrepresents a broad set of individual numerical types understood aspermutations of a half-dozen or so basic attributes. The other basicproperty of any slaw is its size. In an embodiment, slawx havebyte-lengths quantized to multiples of four; these four-byte words arereferred to herein as ‘quads’. In general, such quad-based sizing alignsslawx well with the configurations of modern computer hardwarearchitectures.

The first four bytes of every slaw in an embodiment comprise a headerstructure that encodes type-description and other metainformation, andthat ascribes specific type meanings to particular bit patterns. Forexample, the first (most significant) bit of a slaw header is used tospecify whether the size (length in quad-words) of that slaw follows theinitial four-byte type header. When this bit is set, it is understoodthat the size of the slaw is explicitly recorded in the next four bytesof the slaw (e.g., bytes five through eight); if the size of the slaw issuch that it cannot be represented in four bytes (i.e. if the size is oris larger than two to the thirty-second power) then thenext-most-significant bit of the slaw's initial four bytes is also set,which means that the slaw has an eight-byte (rather than four byte)length. In that case, an inspecting process will find the slaw's lengthstored in ordinal bytes five through twelve. On the other hand, thesmall number of slaw types means that in many cases a fully specifiedtypal bit-pattern “leaves unused” many bits in the four byte slawheader; and in such cases these bits may be employed to encode theslaw's length, saving the bytes (five through eight) that wouldotherwise be required.

For example, an embodiment leaves the most significant bit of the slawheader (the “length follows” flag) unset and sets the next bit toindicate that the slaw is a “wee cons”, and in this case the length ofthe slaw (in quads) is encoded in the remaining thirty bits. Similarly,a “wee string” is marked by the pattern 001 in the header, which leavestwenty-nine bits for representation of the slaw-string's length; and aleading 0001 in the header describes a “wee list”, which by virtue ofthe twenty-eight available length-representing bits can be a slaw listof up to two-to-the-twenty-eight quads in size. A “full string” (or consor list) has a different bit signature in the header, with the mostsignificant header bit necessarily set because the slaw length isencoded separately in bytes five through eight (or twelve, in extremecases). Note that the Plasma implementation “decides” at the instant ofslaw construction whether to employ the “wee” or the “full” version ofthese constructs (the decision is based on whether the resulting sizewill “fit” in the available wee bits or not), but the full-vs.-weedetail is hidden from the user of the Plasma implementation, who knowsand cares only that she is using a slaw string, or a slaw cons, or aslaw list.

Numeric slawx are, in an embodiment, indicated by the leading headerpattern 00001. Subsequent header bits are used to represent a set oforthogonal properties that may be combined in arbitrary permutation. Anembodiment employs, but is not limited to, five such character bits toindicate whether or not the number is: (1) floating point; (2) complex;(3) unsigned; (4) “wide”; (5) “stumpy” ((4) “wide” and (5) “stumpy” arepermuted to indicate eight, sixteen, thirty-two, and sixty-four bitnumber representations). Two additional bits (e.g., (7) and (8))indicate that the encapsulated numeric data is a two-, three-, orfour-element vector (with both bits being zero suggesting that thenumeric is a “one-element vector” (i.e. a scalar)). In this embodimentthe eight bits of the fourth header byte are used to encode the size (inbytes, not quads) of the encapsulated numeric data. This size encodingis offset by one, so that it can represent any size between andincluding one and two hundred fifty-six bytes. Finally, two characterbits (e.g., (9) and (10)) are used to indicate that the numeric dataencodes an array of individual numeric entities, each of which is of thetype described by character bits (1) through (8). In the case of anarray, the individual numeric entities are not each tagged withadditional headers, but are packed as continuous data following thesingle header and, possibly, explicit slaw size information.

This embodiment affords simple and efficient slaw duplication (which canbe implemented as a byte-for-byte copy) and extremely straightforwardand efficient slaw comparison (two slawx are the same in this embodimentif and only if there is a one-to-one match of each of their componentbytes considered in sequence). This latter property is important, forexample, to an efficient implementation of the protein architecture, oneof whose critical and pervasive features is the ability to searchthrough or ‘match on’ a protein's descrips list.

Further, the embodiments herein allow aggregate slaw forms (e.g., theslaw cons and the slaw list) to be constructed simply and efficiently.For example, an embodiment builds a slaw cons from two component slawx,which may be of any type, including themselves aggregates, by: (a)querying each component slaw's size; (b) allocating memory of size equalto the sum of the sizes of the two component slawx and the one, two, orthree quads needed for the header-plus-size structure; (c) recording theslaw header (plus size information) in the first four, eight, or twelvebytes; and then (d) copying the component slawx's bytes in turn into theimmediately succeeding memory. Significantly, such a constructionroutine need know nothing about the types of the two component slawx;only their sizes (and accessibility as a sequence of bytes) matters. Thesame process pertains to the construction of slaw lists, which areordered encapsulations of arbitrarily many sub-slawx of (possibly)heterogeneous type.

A further consequence of the slaw system's fundamental format assequential bytes in memory obtains in connection with “traversal”activities—a recurring use pattern uses, for example, sequential accessto the individual slawx stored in a slaw list. The individual slawx thatrepresent the descrips and ingests within a protein structure mustsimilarly be traversed. Such maneuvers are accomplished in a stunninglystraightforward and efficient manner: to “get to” the next slaw in aslaw list, one adds the length of the current slaw to its location inmemory, and the resulting memory location is identically the header ofthe next slaw. Such simplicity is possible because the slaw and proteindesign eschews “indirection”; there are no pointers; rather, the datasimply exists, in its totality, in situ.

To the point of slaw comparison, a complete implementation of the Plasmasystem must acknowledge the existence of differing and incompatible datarepresentation schemes across and among different operating systems,CPUs, and hardware architectures. Major such differences includebyte-ordering policies (e.g., little- vs. big-endianness) andfloating-point representations; other differences exist. The Plasmaspecification requires that the data encapsulated by slawx be guaranteedinterprable (i.e., must appear in the native format of the architectureor platform from which the slaw is being inspected. This requirementmeans in turn that the Plasma system is itself responsible for dataformat conversion. However, the specification stipulates only that theconversion take place before a slaw becomes “at all visible” to anexecuting process that might inspect it. It is therefore up to theindividual implementation at which point it chooses to perform suchformat c conversion; two appropriate approaches are that slaw datapayloads are conformed to the local architecture's data format (1) as anindividual slaw is “pulled out” of a protein in which it had beenpacked, or (2) for all slaw in a protein simultaneously, as that proteinis extracted from the pool in which it was resident. Note that theconversion stipulation considers the possibility of hardware-assistedimplementations. For example, networking chipsets built with explicitPlasma capability may choose to perform format conversion intelligentlyand at the “instant of transmission”, based on the known characteristicsof the receiving system. Alternately, the process of transmission mayconvert data payloads into a canonical format, with the receivingprocess symmetrically converting from canonical to “local” format.Another embodiment performs format conversion “at the metal”, meaningthat data is always stored in canonical format, even in local memory,and that the memory controller hardware itself performs the conversionas data is retrieved from memory and placed in the registers of theproximal CPU.

A minimal (and read-only) protein implementation of an embodimentincludes operation or behavior in one or more applications orprogramming languages making use of proteins. FIG. 6B is a flow diagram650 for using proteins, under an embodiment. Operation begins byquerying 652 the length in bytes of a protein. The number of descripsentries is queried 654. The number of ingests is queried 656. A descripentry is retrieved 658 by index number. An ingest is retrieved 660 byindex number.

The embodiments described herein also define basic methods allowingproteins to be constructed and filled with data, helper-methods thatmake common tasks easier for programmers, and hooks for creatingoptimizations. FIG. 6C is a flow diagram 670 for constructing orgenerating proteins, under an embodiment. Operation begins with creation672 of a new protein. A series of descrips entries are appended 674. Aningest is also appended 676. The presence of a matching descrip isqueried 678, and the presence of a matching ingest key is queried 680.Given an ingest key, an ingest value is retrieved 682. Pattern matchingis performed 684 across descrips. Non-structured metadata is embedded686 near the beginning of the protein.

As described above, slawx provide the lowest-level of data definitionfor inter-process exchange, proteins provide mid-level structure andhooks for querying and filtering, and pools provide for high-levelorganization and access semantics. The pool is a repository forproteins, providing linear sequencing and state caching. The pool alsoprovides multi-process access by multiple programs or applications ofnumerous different types. Moreover, the pool provides a set of common,optimizable filtering and pattern-matching behaviors.

The pools of an embodiment, which can accommodate tens of thousands ofproteins, function to maintain state, so that individual processes canoffload much of the tedious bookkeeping common to multi-process programcode. A pool maintains or keeps a large buffer of past proteinsavailable—the Platonic pool is explicitly infinite—so that participatingprocesses can scan both backwards and forwards in a pool at will. Thesize of the buffer is implementation dependent, of course, but in commonusage it is often possible to keep proteins in a pool for hours or days.

The most common style of pool usage as described herein hews to abiological metaphor, in contrast to the mechanistic, point-to-pointapproach taken by existing inter-process communication frameworks. Thename protein alludes to biological inspiration: data proteins in poolsare available for flexible querying and pattern matching by a largenumber of computational processes, as chemical proteins in a livingorganism are available for pattern matching and filtering by largenumbers of cellular agents.

Two additional abstractions lean on the biological metaphor, includinguse of “handlers”, and the Golgi framework. A process that participatesin a pool generally creates a number of handlers. Handlers arerelatively small bundles of code that associate match conditions withhandle behaviors. By tying one or more handlers to a pool, a processsets up flexible call-back triggers that encapsulate state and react tonew proteins.

A process that participates in several pools generally inherits from anabstract Golgi class. The Golgi framework provides a number of usefulroutines for managing multiple pools and handlers. The Golgi class alsoencapsulates parent-child relationships, providing a mechanism for localprotein exchange that does not use a pool.

A pools API provided under an embodiment is configured to allow pools tobe implemented in a variety of ways, in order to account both forsystem-specific goals and for the available capabilities of givenhardware and network architectures. The two fundamental systemprovisions upon which pools depend are a storage facility and a means ofinter-process communication. The extant systems described herein use aflexible combination of shared memory, virtual memory, and disk for thestorage facility, and IPC queues and TCP/IP sockets for inter-processcommunication.

Pool functionality of an embodiment includes, but is not limited to, thefollowing: participating in a pool; placing a protein in a pool;retrieving the next unseen protein from a pool; rewinding orfast-forwarding through the contents (e.g., proteins) within a pool.Additionally, pool functionality can include, but is not limited to, thefollowing: setting up a streaming pool call-back for a process;selectively retrieving proteins that match particular patterns ofdescrips or ingests keys; scanning backward and forwards for proteinsthat match particular patterns of descrips or ingests keys.

The proteins described above are provided to pools as a way of sharingthe protein data contents with other applications. FIG. 7 is a blockdiagram of a processing environment including data exchange using slawx,proteins, and pools, under an embodiment. This example environmentincludes three devices (e.g., Device X, Device Y, and Device Z,collectively referred to herein as the “devices”) sharing data throughthe use of slawx, proteins and pools as described above. Each of thedevices is coupled to the three pools (e.g., Pool 1, Pool 2, Pool 3).Pool 1 includes numerous proteins (e.g., Protein X1, Protein Z2, ProteinY2, Protein X4, Protein Y4) contributed or transferred to the pool fromthe respective devices (e.g., protein Z2 is transferred or contributedto pool 1 by device Z, etc.). Pool 2 includes numerous proteins (e.g.,Protein Z4, Protein Y3, Protein Z1, Protein X3) contributed ortransferred to the pool from the respective devices (e.g., protein Y3 istransferred or contributed to pool 2 by device Y, etc.). Pool 3 includesnumerous proteins (e.g., Protein Y1, Protein Z3, Protein X2) contributedor transferred to the pool from the respective devices (e.g., protein X2is transferred or contributed to pool 3 by device X, etc.). While theexample described above includes three devices coupled or connectedamong three pools, any number of devices can be coupled or connected inany manner or combination among any number of pools, and any pool caninclude any number of proteins contributed from any number orcombination of devices. The proteins and pools of this example are asdescribed above with reference to FIGS. 1-6.

FIG. 8 is a block diagram of a processing environment including multipledevices and numerous programs running on one or more of the devices inwhich the Plasma constructs (e.g., pools, proteins, and slaw) are usedto allow the numerous running programs to share and collectively respondto the events generated by the devices, under an embodiment. This systemis but one example of a multi-user, multi-device, multi-computerinteractive control scenario or configuration. More particularly, inthis example, an interactive system, comprising multiple devices (e.g.,device A, B, etc.) and a number of programs (e.g., apps AA-AX, appsBA-BX, etc.) running on the devices uses the Plasma constructs (e.g.,pools, proteins, and slaw) to allow the running programs to share andcollectively respond to the events generated by these input devices.

In this example, each device (e.g., device A, B, etc.) translatesdiscrete raw data generated by or output from the programs (e.g., appsAA-AX, apps BA-BX, etc.) running on that respective device into Plasmaproteins and deposits those proteins into a Plasma pool. For example,program AX generates data or output and provides the output to device Awhich, in turn, translates the raw data into proteins (e.g., protein 1A,protein 2A, etc.) and deposits those proteins into the pool. As anotherexample, program BC generates data and provides the data to device Bwhich, in turn, translates the data into proteins (e.g., protein 1B,protein 2B, etc.) and deposits those proteins into the pool.

Each protein contains a descrip list that specifies the data or outputregistered by the application as well as identifying information for theprogram itself. Where possible, the protein descrips may also ascribe ageneral semantic meaning for the output event or action. The protein'sdata payload (e.g., ingests) carries the full set of useful stateinformation for the program event.

The proteins, as described above, are available in the pool for use byany program or device coupled or connected to the pool, regardless oftype of the program or device. Consequently, any number of programsrunning on any number of computers may extract event proteins from theinput pool. These devices need only be able to participate in the poolvia either the local memory bus or a network connection in order toextract proteins from the pool. An immediate consequence of this is thebeneficial possibility of decoupling processes that are responsible forgenerating processing events from those that use or interpret theevents. Another consequence is the multiplexing of sources and consumersof events so that devices may be controlled by one person or may be usedsimultaneously by several people (e.g., a Plasma-based input frameworksupports many concurrent users), while the resulting event streams arein turn visible to multiple event consumers.

As an example, device C can extract one or more proteins (e.g., protein1A, protein 2A, etc.) from the pool. Following protein extraction,device C can use the data of the protein, retrieved or read from theslaw of the descrips and ingests of the protein, in processing events towhich the protein data corresponds. As another example, device B canextract one or more proteins (e.g., protein 1C, protein 2A, etc.) fromthe pool. Following protein extraction, device B can use the data of theprotein in processing events to which the protein data corresponds.

Devices and/or programs coupled or connected to a pool may skimbackwards and forwards in the pool looking for particular sequences ofproteins. It is often useful, for example, to set up a program to waitfor the appearance of a protein matching a certain pattern, then skimbackwards to determine whether this protein has appeared in conjunctionwith certain others. This facility for making use of the stored eventhistory in the input pool often makes writing state management codeunnecessary, or at least significantly reduces reliance on suchundesirable coding patterns.

FIG. 9 is a block diagram of a processing environment including multipledevices and numerous programs running on one or more of the devices inwhich the Plasma constructs (e.g., pools, proteins, and slaw) are usedto allow the numerous running programs to share and collectively respondto the events generated by the devices, under an alternative embodiment.This system is but one example of a multi-user, multi-device,multi-computer interactive control scenario or configuration. Moreparticularly, in this example, an interactive system, comprisingmultiple devices (e.g., devices X and Y coupled to devices A and B,respectively) and a number of programs (e.g., apps AA-AX, apps BA-BX,etc.) running on one or more computers (e.g., device A, device B, etc.)uses the Plasma constructs (e.g., pools, proteins, and slaw) to allowthe running programs to share and collectively respond to the eventsgenerated by these input devices.

In this example, each device (e.g., devices X and Y coupled to devices Aand B, respectively) is managed and/or coupled to run under or inassociation with one or more programs hosted on the respective device(e.g., device A, device B, etc.) which translates the discrete raw datagenerated by the device (e.g., device X, device A, device Y, device B,etc.) hardware into Plasma proteins and deposits those proteins into aPlasma pool. For example, device X running in association withapplication AB hosted on device A generates raw data, translates thediscrete raw data into proteins (e.g., protein 1A, protein 2A, etc.) anddeposits those proteins into the pool. As another example, device Xrunning in association with application AT hosted on device A generatesraw data, translates the discrete raw data into proteins (e.g., protein1A, protein 2A, etc.) and deposits those proteins into the pool. As yetanother example, device Z running in association with application CDhosted on device C generates raw data, translates the discrete raw datainto proteins (e.g., protein 1C, protein 2C, etc.) and deposits thoseproteins into the pool.

Each protein contains a descrip list that specifies the actionregistered by the input device as well as identifying information forthe device itself. Where possible, the protein descrips may also ascribea general semantic meaning for the device action. The protein's datapayload (e.g., ingests) carries the full set of useful state informationfor the device event.

The proteins, as described above, are available in the pool for use byany program or device coupled or connected to the pool, regardless oftype of the program or device. Consequently, any number of programsrunning on any number of computers may extract event proteins from theinput pool. These devices need only be able to participate in the poolvia either the local memory bus or a network connection in order toextract proteins from the pool. An immediate consequence of this is thebeneficial possibility of decoupling processes that are responsible forgenerating processing events from those that use or interpret theevents. Another consequence is the multiplexing of sources and consumersof events so that input devices may be controlled by one person or maybe used simultaneously by several people (e.g., a Plasma-based inputframework supports many concurrent users), while the resulting eventstreams are in turn visible to multiple event consumers.

Devices and/or programs coupled or connected to a pool may skimbackwards and forwards in the pool looking for particular sequences ofproteins. It is often useful, for example, to set up a program to waitfor the appearance of a protein matching a certain pattern, then skimbackwards to determine whether this protein has appeared in conjunctionwith certain others. This facility for making use of the stored eventhistory in the input pool often makes writing state management codeunnecessary, or at least significantly reduces reliance on suchundesirable coding patterns.

FIG. 10 is a block diagram of a processing environment includingmultiple input devices coupled among numerous programs running on one ormore of the devices in which the Plasma constructs (e.g., pools,proteins, and slaw) are used to allow the numerous running programs toshare and collectively respond to the events generated by the inputdevices, under another alternative embodiment. This system is but oneexample of a multi-user, multi-device, multi-computer interactivecontrol scenario or configuration. More particularly, in this example,an interactive system, comprising multiple input devices (e.g., inputdevices A, B, BA, and BB, etc.) and a number of programs (not shown)running on one or more computers (e.g., device A, device B, etc.) usesthe Plasma constructs (e.g., pools, proteins, and slaw) to allow therunning programs to share and collectively respond to the eventsgenerated by these input devices.

In this example, each input device (e.g., input devices A, B, BA, andBB, etc.) is managed by a software driver program hosted on therespective device (e.g., device A, device B, etc.) which translates thediscrete raw data generated by the input device hardware into Plasmaproteins and deposits those proteins into a Plasma pool. For example,input device A generates raw data and provides the raw data to device Awhich, in turn, translates the discrete raw data into proteins (e.g.,protein 1A, protein 2A, etc.) and deposits those proteins into the pool.As another example, input device BB generates raw data and provides theraw data to device B which, in turn, translates the discrete raw datainto proteins (e.g., protein 1B, protein 3B, etc.) and deposits thoseproteins into the pool.

Each protein contains a descrip list that specifies the actionregistered by the input device as well as identifying information forthe device itself. Where possible, the protein descrips may also ascribea general semantic meaning for the device action. The protein's datapayload (e.g., ingests) carries the full set of useful state informationfor the device event.

To illustrate, here are example proteins for two typical events in sucha system. Proteins are represented here as text however, in an actualimplementation, the constituent parts of these proteins are typed databundles (e.g., slaw). The protein describing a g-speak “one fingerclick” pose (described in the Related Applications) is as follows:

-   -   [Descrips: {point, engage, one, one-finger-engage, hand,        pilot-id-02, hand-id-23}    -   Ingests: {pilot-id=>02, hand-id=>23, pos=>[0.0, 0.0, 0.0]        angle-axis=>[0.0, 0.0, 0.0, 0.707] gripe=>..{circumflex over        ( )}∥:vx time=>184437103.29}]

As a further example, the protein describing a mouse click is asfollows:

-   -   [Descrips: {point, click, one, mouse-click, button-one,        mouse-id-02}    -   Ingests: {mouse-id=>23, pos=>[0.0, 0.0, 0.0]        time=>184437124.80}]

Either or both of the sample proteins foregoing might cause aparticipating program of a host device to run a particular portion ofits code. These programs may be interested in the general semanticlabels: the most general of all, “point”, or the more specific pair,“engage, one”. Or they may be looking for events that would plausibly begenerated only by a precise device: “one-finger-engage”, or even asingle aggregate object, “hand-id-23”.

The proteins, as described above, are available in the pool for use byany program or device coupled or connected to the pool, regardless oftype of the program or device. Consequently, any number of programsrunning on any number of computers may extract event proteins from theinput pool. These devices need only be able to participate in the poolvia either the local memory bus or a network connection in order toextract proteins from the pool. An immediate consequence of this is thebeneficial possibility of decoupling processes that are responsible forgenerating ‘input events’ from those that use or interpret the events.Another consequence is the multiplexing of sources and consumers ofevents so that input devices may be controlled by one person or may beused simultaneously by several people (e.g., a Plasma-based inputframework supports many concurrent users), while the resulting eventstreams are in turn visible to multiple event consumers.

As an example or protein use, device C can extract one or more proteins(e.g., protein 1B, etc.) from the pool. Following protein extraction,device C can use the data of the protein, retrieved or read from theslaw of the descrips and ingests of the protein, in processing inputevents of input devices CA and CC to which the protein data corresponds.As another example, device A can extract one or more proteins (e.g.,protein 1B, etc.) from the pool. Following protein extraction, device Acan use the data of the protein in processing input events of inputdevice A to which the protein data corresponds.

Devices and/or programs coupled or connected to a pool may skimbackwards and forwards in the pool looking for particular sequences ofproteins. It is often useful, for example, to set up a program to waitfor the appearance of a protein matching a certain pattern, then skimbackwards to determine whether this protein has appeared in conjunctionwith certain others. This facility for making use of the stored eventhistory in the input pool often makes writing state management codeunnecessary, or at least significantly reduces reliance on suchundesirable coding patterns.

Examples of input devices that are used in the embodiments of the systemdescribed herein include gestural input sensors, keyboards, mice,infrared remote controls such as those used in consumer electronics, andtask-oriented tangible media objects, to name a few.

FIG. 11 is a block diagram of a processing environment includingmultiple devices coupled among numerous programs running on one or moreof the devices in which the Plasma constructs (e.g., pools, proteins,and slaw) are used to allow the numerous running programs to share andcollectively respond to the graphics events generated by the devices,under yet another alternative embodiment. This system is but one exampleof a system comprising multiple running programs (e.g. graphics A-E) andone or more display devices (not shown), in which the graphical outputof some or all of the programs is made available to other programs in acoordinated manner using the Plasma constructs (e.g., pools, proteins,and slaw) to allow the running programs to share and collectivelyrespond to the graphics events generated by the devices.

It is often useful for a computer program to display graphics generatedby another program. Several common examples include video conferencingapplications, network-based slideshow and demo programs, and windowmanagers. Under this configuration, the pool is used as a Plasma libraryto implement a generalized framework which encapsulates video, networkapplication sharing, and window management, and allows programmers toadd in a number of features not commonly available in current versionsof such programs.

Programs (e.g., graphics A-E) running in the Plasma compositingenvironment participate in a coordination pool through couplings and/orconnections to the pool. Each program may deposit proteins in that poolto indicate the availability of graphical sources of various kinds.Programs that are available to display graphics also deposit proteins toindicate their displays' capabilities, security and user profiles, andphysical and network locations.

Graphics data also may be transmitted through pools, or display programsmay be pointed to network resources of other kinds (RTSP streams, forexample). The phrase “graphics data” as used herein refers to a varietyof different representations that lie along a broad continuum; examplesof graphics data include but are not limited to literal examples (e.g.,an ‘image’, or block of pixels), procedural examples (e.g., a sequenceof ‘drawing’ directives, such as those that flow down a typical openGLpipeline), and descriptive examples (e.g., instructions that combineother graphical constructs by way of geometric transformation, clipping,and compositing operations).

On a local machine graphics data may be delivered throughplatform-specific display driver optimizations. Even when graphics arenot transmitted via pools, often a periodic screen-capture will bestored in the coordination pool so that clients without direct access tothe more esoteric sources may still display fall-back graphics.

One advantage of the system described here is that unlike most messagepassing frameworks and network protocols, pools maintain a significantbuffer of data. So programs can rewind backwards into a pool looking ataccess and usage patterns (in the case of the coordination pool) orextracting previous graphics frames (in the case of graphics pools).

FIG. 12 is a block diagram of a processing environment includingmultiple devices coupled among numerous programs running on one or moreof the devices in which the Plasma constructs (e.g., pools, proteins,and slaw) are used to allow stateful inspection, visualization, anddebugging of the running programs, under still another alternativeembodiment. This system is but one example of a system comprisingmultiple running programs (e.g. program P-A, program P-B, etc.) onmultiple devices (e.g., device A, device B, etc.) in which some programsaccess the internal state of other programs using or via pools.

Most interactive computer systems comprise many programs runningalongside one another, either on a single machine or on multiplemachines and interacting across a network. Multi-program systems can bedifficult to configure, analyze and debug because run-time data ishidden inside each process and difficult to access. The generalizedframework and Plasma constructs of an embodiment described herein allowrunning programs to make much of their data available via pools so thatother programs may inspect their state. This framework enables debuggingtools that are more flexible than conventional debuggers, sophisticatedsystem maintenance tools, and visualization harnesses configured toallow human operators to analyze in detail the sequence of states that aprogram or programs has passed through.

Referring to FIG. 12, a program (e.g., program P-A, program P-B, etc.)running in this framework generates or creates a process pool uponprogram start up. This pool is registered in the system almanac, andsecurity and access controls are applied. More particularly, each device(e.g., device A, B, etc.) translates discrete raw data generated by oroutput from the programs (e.g., program P-A, program P-B, etc.) runningon that respective device into Plasma proteins and deposits thoseproteins into a Plasma pool. For example, program P-A generates data oroutput and provides the output to device A which, in turn, translatesthe raw data into proteins (e.g., protein 1A, protein 2A, protein 3A,etc.) and deposits those proteins into the pool. As another example,program P-B generates data and provides the data to device B which, inturn, translates the data into proteins (e.g., proteins 1B-4B, etc.) anddeposits those proteins into the pool.

For the duration of the program's lifetime, other programs withsufficient access permissions may attach to the pool and read theproteins that the program deposits; this represents the basic inspectionmodality, and is a conceptually “one-way” or “read-only” proposition:entities interested in a program P-A inspect the flow of statusinformation deposited by P-A in its process pool. For example, aninspection program or application running under device C can extract oneor more proteins (e.g., protein 1A, protein 2A, etc.) from the pool.Following protein extraction, device C can use the data of the protein,retrieved or read from the slaw of the descrips and ingests of theprotein, to access, interpret and inspect the internal state of programP-A.

But, recalling that the Plasma system is not only an efficient statefultransmission scheme but also an omnidirectional messaging environment,several additional modes support program-to-program state inspection. Anauthorized inspection program may itself deposit proteins into programP's process pool to influence or control the characteristics of stateinformation produced and placed in that process pool (which, after all,program P not only writes into but reads from).

FIG. 13 is a block diagram of a processing environment includingmultiple devices coupled among numerous programs running on one or moreof the devices in which the Plasma constructs (e.g., pools, proteins,and slaw) are used to allow influence or control the characteristics ofstate information produced and placed in that process pool, under anadditional alternative embodiment. In this system example, theinspection program of device C can for example request that programs(e.g., program P-A, program P-B, etc.) dump more state than normal intothe pool, either for a single instant or for a particular duration. Or,prefiguring the next ‘level’ of debug communication, an interestedprogram can request that programs (e.g., program P-A, program P-B, etc.)emit a protein listing the objects extant in its runtime environmentthat are individually capable of and available for interaction via thedebug pool. Thus informed, the interested program can ‘address’individuals among the objects in the programs runtime, placing proteinsin the process pool that a particular object alone will take up andrespond to. The interested program might, for example, request that anobject emit a report protein describing the instantaneous values of allits component variables. Even more significantly, the interested programcan, via other proteins, direct an object to change its behavior or itsvariables' values.

More specifically, in this example, inspection application of device Cplaces into the pool a request (in the form of a protein) for an objectlist (e.g., “Request-Object List”) that is then extracted by each device(e.g., device A, device B, etc.) coupled to the pool. In response to therequest, each device (e.g., device A, device B, etc.) places into thepool a protein (e.g., protein 1A, protein 1B, etc.) listing the objectsextant in its runtime environment that are individually capable of andavailable for interaction via the debug pool.

Thus informed via the listing from the devices, and in response to thelisting of the objects, the inspection application of device C addressesindividuals among the objects in the programs runtime, placing proteinsin the process pool that a particular object alone will take up andrespond to. The inspection application of device C can, for example,place a request protein (e.g., protein “Request Report P-A-O”, “RequestReport P-B-O”) in the pool that an object (e.g., object P-A-O, objectP-B-O, respectively) emit a report protein (e.g., protein 2A, protein2B, etc.) describing the instantaneous values of all its componentvariables. Each object (e.g., object P-A-O, object P-B-O) extracts itsrequest (e.g., protein “Request Report P-A-O”, “Request Report P-B-O”,respectively) and, in response, places a protein into the pool thatincludes the requested report (e.g., protein 2A, protein 2B,respectively). Device C then extracts the various report proteins (e.g.,protein 2A, protein 2B, etc.) and takes subsequent processing action asappropriate to the contents of the reports.

In this way, use of Plasma as an interchange medium tends ultimately toerode the distinction between debugging, process control, andprogram-to-program communication and coordination.

To that last, the generalized Plasma framework allows visualization andanalysis programs to be designed in a loosely-coupled fashion. Avisualization tool that displays memory access patterns, for example,might be used in conjunction with any program that outputs its basicmemory reads and writes to a pool. The programs undergoing analysis neednot know of the existence or design of the visualization tool, and viceversa.

The use of pools in the manners described above does not unduly affectsystem performance. For example, embodiments have allowed for depositingof several hundred thousand proteins per second in a pool, so thatenabling even relatively verbose data output does not noticeably inhibitthe responsiveness or interactive character of most programs.

Examples of the systems and methods described above include a methodcomprising: detecting an event of a source device; generating at leastone data sequence comprising device event data specifying the event andstate information of the event, wherein the device event data and stateinformation are type-specific data having a type corresponding to anapplication of the source device; and forming a data capsule to includethe at least one data sequence, the data capsule having a data structurecomprising an application-independent representation of the at least onedata sequence.

The generating of the at least one data sequence of an embodimentcomprises: generating a first respective data set that includes firstrespective device event data; generating a second respective data setthat includes second respective state information; and forming a firstdata sequence to include the first respective data set and the secondrespective data set.

The generating of the first respective data set of an embodimentincludes forming the first respective data set to include identificationdata of the source device, the identification data including dataidentifying the source device.

The generating of the at least one data sequence of an embodimentcomprises: generating a first respective data set that includes firstrespective device event data; generating a second respective data setthat includes second respective state information; and forming a seconddata sequence to include the first respective data set and the secondrespective data set.

The generating of the first respective data set of an embodimentincludes generating a first respective data set offset, wherein thefirst respective data set offset points to the first respective data setof the second data sequence.

The generating of the second respective data set of an embodimentincludes generating a second respective data set offset, wherein thesecond respective data set offset points to the second respective dataset of the second data sequence.

The first respective data set of an embodiment is a description list,the description list including a description of the data.

The device event data of an embodiment is a tagged byte-sequencerepresenting typed data.

The device event data of an embodiment includes a type header and atype-specific data layout.

The state information of an embodiment is a tagged byte-sequencerepresenting typed data.

The state information of an embodiment includes a type header and atype-specific data layout.

The method of an embodiment comprises: generating at least one offset;and forming the data capsule to include the at least one offset.

The method of an embodiment comprises: generating a first offset havinga first variable length; wherein the first offset points to the deviceevent data of a first data sequence of the at least one data sequence.

The method of an embodiment comprises: generating a second offset havinga second variable length; wherein the second offset points to the stateinformation of a first data sequence of the at least one data sequence.

The method of an embodiment comprises: forming a first code path throughthe data capsule using a first offset of the at least one offset;forming a second code path through the data capsule using a secondoffset of the at least one offset; wherein the first code path and thesecond code path are different paths.

At least one of the first offset and the second offset of an embodimentinclude metadata, the metadata comprising context-specific metadatacorresponding to a context of the application.

The method of an embodiment comprises: generating a header that includesa length of the data capsule; forming the data capsule to include theheader.

The method of an embodiment comprises transferring the data capsule to arepository.

The method of an embodiment comprises: detecting a second event of asecond source device; searching the repository for data capsulescorresponding to the second event.

The method of an embodiment comprises: identifying a correspondencebetween the data capsule and the second event; extracting the datacapsule from the repository in response to the identifying; andexecuting on behalf of the second source device a processing operationcorresponding to the second event on behalf of the second source devicein response to contents of the data capsule, wherein the source devicecorresponds to an application of a first type and the second sourcedevice corresponds to a second application of a second type.

The repository of an embodiment is coupled to a plurality ofapplications, the repository including a plurality of data capsulescorresponding to the plurality of applications, the repository providingaccess to the plurality of data capsules by the plurality ofapplications, wherein at least two applications of the plurality ofapplications are different applications.

The repository of an embodiment provides state caching of a plurality ofdata capsules.

The repository of an embodiment provides linear sequencing of aplurality of data capsules.

The data structure of an embodiment is untyped.

The data structure of the data capsule of an embodiment provides aplatform-independent representation of the device event data and thestate information.

The data structure of the data capsule of an embodiment providesplatform-independent access to the device event data and the stateinformation.

The method of an embodiment comprises: transferring the data capsulefrom a first application having a first application type to at least onesecond application having at least one second application type, whereinthe first application type is different than the second applicationtype, wherein the generating of the at least one data sequence wasexecuted by the first application; and maintaining intact the at leastone data sequence of the data capsule during the transferring.

The method of an embodiment comprises using the at least one datasequence during operations of the second application.

The event of an embodiment comprises a user interface event.

The event of an embodiment comprises a graphics event.

The event of an embodiment comprises depositing of state information.

Examples of the systems and methods described above include a methodcomprising: generating a first data set that includes device event dataand identification data of a source device, the device event dataincluding data specifying an event registered by the source device, theidentification data including data identifying the source device;generating a second data set that includes a full set of stateinformation of the event; wherein each of the first data set and thesecond data set comprise typed data bundles in a type-specific datalayout; and encapsulating the first data set and the second data set byforming a data capsule to include the first data set and the second dataset, wherein the data capsule has a data structure comprising anapplication-independent representation of the at least one datasequence.

Examples of the systems and methods described above include a methodcomprising: detecting an event of a device running under an applicationof a first type; generating data sequences comprising device event dataspecifying the event and state information of the event, wherein thedevice event data and state information are type-specific data having atype corresponding to the application; forming a data capsule to includethe data sequences, the data capsule having a data structure comprisingan application-independent representation of the data sequences;detecting a second event of at least one second source device runningunder at least one second application having at least one second type,wherein the second type is different from the first type; identifying acorrespondence between the data capsule and the second event; andexecuting an operation in response to the second event using contents ofthe data sequences of the data capsule.

The generating of the data sequences of an embodiment comprises:generating a first data set that includes the device event data;generating a second data set that includes the state information; andforming a first data sequence to include the first data set and thesecond data set.

The device event data of an embodiment is a tagged byte-sequencerepresenting typed data.

The device event data of an embodiment includes a type header and atype-specific data layout.

The state information of an embodiment is a tagged byte-sequencerepresenting typed data.

The state information of an embodiment includes a type header and atype-specific data layout.

The method of an embodiment comprises: generating at least one offset;and forming the data capsule to include the at least one offset.

The method of an embodiment comprises: generating a first offset havinga first variable length, wherein the first offset points to the deviceevent data of a first data sequence of the at least one data sequence;and generating a second offset having a second variable length, whereinthe second offset points to the state information of a first datasequence of the at least one data sequence.

The method of an embodiment comprises: forming a first code path throughthe data capsule using a first offset of the at least one offset;forming a second code path through the data capsule using a secondoffset of the at least one offset; wherein the first code path and thesecond code path are different paths.

At least one of the first offset and the second offset of an embodimentinclude metadata, the metadata comprising context-specific metadatacorresponding to a context of the application.

The method of an embodiment comprises transferring the data capsule to arepository.

The method of an embodiment comprises: searching the repository for datacapsules corresponding to the second event; and extracting the datacapsule from the repository in response to the identifying of thecorrespondence.

The repository of an embodiment is coupled to the application and the atleast one second application, the repository including a plurality ofdata capsules corresponding to the application and the at least onesecond application, the repository providing access to the plurality ofdata capsules by the application and the at least one secondapplication.

The repository of an embodiment provides state caching of a plurality ofdata capsules.

The repository of an embodiment provides linear sequencing of aplurality of data capsules.

The data structure of an embodiment is untyped.

The data structure of the data capsule of an embodiment provides aplatform-independent representation of the device event data and thestate information.

The data structure of the data capsule of an embodiment providesplatform-independent access to the device event data and the stateinformation.

Examples of the systems and methods described above include a methodcomprising: detecting an event of a first source device running under anapplication of a first type; generating data sequences comprising deviceevent data specifying the event and state information of the event,wherein the device event data and state information are type-specificdata having a type corresponding to the application; forming a datacapsule to include the data sequences, wherein the data capsule has adata structure comprising an application-independent representation ofthe data sequences; placing the data capsule in a repository; detectinga second event of at least one second source device running under atleast one second application having at least one second type; searchingthe repository and identifying a correspondence between the data capsuleand the second event; and executing on behalf of the second sourcedevice an operation corresponding to the second event using contents ofthe data sequences of the data capsule.

The systems and methods described herein, including systems and methodsfor encapsulating data through the use of slawx, proteins, and pools,and transferring and using the encapsulated data, include and/or rununder and/or in association with a processing system. The processingsystem includes any collection of processor-based devices or computingdevices operating together, or components of processing systems ordevices, as is known in the art. For example, the processing system caninclude one or more of a portable computer, portable communicationdevice operating in a communication network, and/or a network server.The portable computer can be any of a number and/or combination ofdevices selected from among personal computers, cellular telephones,personal digital assistants, portable computing devices, and portablecommunication devices, but is not so limited. The processing system caninclude components within a larger computer system.

The processing system of an embodiment includes at least one processorand at least one memory device or subsystem. The processing system canalso include or be coupled to at least one database. The term“processor” as generally used herein refers to any logic processingunit, such as one or more central processing units (CPUs), digitalsignal processors (DSPs), application-specific integrated circuits(ASIC), etc. The processor and memory can be monolithically integratedonto a single chip, distributed among a number of chips or components ofa host system, and/or provided by some combination of algorithms. Themethods described herein can be implemented in one or more of softwarealgorithm(s), programs, firmware, hardware, components, circuitry, inany combination.

System components embodying the systems and methods described herein canbe located together or in separate locations. Consequently, systemcomponents embodying the systems and methods described herein can becomponents of a single system, multiple systems, and/or geographicallyseparate systems. These components can also be subcomponents orsubsystems of a single system, multiple systems, and/or geographicallyseparate systems. These components can be coupled to one or more othercomponents of a host system or a system coupled to the host system.

Communication paths couple the system components and include any mediumfor communicating or transferring files among the components. Thecommunication paths include wireless connections, wired connections, andhybrid wireless/wired connections. The communication paths also includecouplings or connections to networks including local area networks(LANs), metropolitan area networks (MANs), wide area networks (WANs),proprietary networks, interoffice or backend networks, and the Internet.Furthermore, the communication paths include removable fixed mediumslike floppy disks, hard disk drives, and CD-ROM disks, as well as flashRAM, Universal Serial Bus (USB) connections, RS-232 connections,telephone lines, buses, and electronic mail messages.

Unless the context clearly requires otherwise, throughout thedescription, the words “comprise,” “comprising,” and the like are to beconstrued in an inclusive sense as opposed to an exclusive or exhaustivesense; that is to say, in a sense of “including, but not limited to.”Words using the singular or plural number also include the plural orsingular number respectively. Additionally, the words “herein,”“hereunder,” “above,” “below,” and words of similar import refer to thisapplication as a whole and not to any particular portions of thisapplication. When the word “or” is used in reference to a list of two ormore items, that word covers all of the following interpretations of theword: any of the items in the list, all of the items in the list and anycombination of the items in the list.

The above description of embodiments of the programming environment isnot intended to be exhaustive or to limit the systems and methodsdescribed to the precise form disclosed. While specific embodiments of,and examples for, the programming environment are described herein forillustrative purposes, various equivalent modifications are possiblewithin the scope of other systems and methods, as those skilled in therelevant art will recognize. The teachings of the programmingenvironment provided herein can be applied to other processing systemsand methods, not only for the systems and methods described above.

The elements and acts of the various embodiments described above can becombined to provide further embodiments. These and other changes can bemade to the programming environment in light of the above detaileddescription.

1. A method comprising: a first device encapsulating first raw inputdata of the first device into a first protein structure and depositingthe first protein structure into an input repository; a second deviceencapsulating second raw input data of the second device into a secondprotein structure and depositing the second protein structure into theinput repository; a third device extracting the first protein structureand the second protein structure from the input repository via at leastone of a local memory bus and a network connection; the third deviceusing the first raw input data of the first protein structure and thesecond raw input data of the second protein structure to process atleast one event corresponding to the first protein structure and thesecond protein structure, wherein the first protein structure and thesecond protein structure have a same record format.